SOLID Design Patterns
HTML-код
- Опубликовано: 2 июн 2024
- In this episode, Robert is joined by Phil Japikse for a chat about design patterns. Software design patterns have been around long before the MVC Framework gained momentum. Phil starts with a review of Robert C. Martin's (Uncle Bob) SOLID macronym. After building the proper foundation,he reviews several design patterns, their C# implementation and when and how they should be used in modern software development.
Get the code samples here: www.skimedic.com/samples/Japik... 
Наука
![Roddy Ricch - Survivors Remorse [Official Music Video]](http://i.ytimg.com/vi/J5IeFzr2GgE/mqdefault.jpg)
14:31 "If you are writing something 3 times you might want to stop being a developer" LOL I died.
For a little context, he was talking about repeated (i.e. non-DRY) code, and with that, I also died. 😋
Great tutorial. Philip made it so that you don't even have to watch the video but just listen to it instead. He walked us through the code just enough verbally. Thanks!
I love listening to Phil Japikse - great sense of humour "Off by one errors" lol. Robert Green is great too because even though he has a ton of knowledge he always asks the kinds of questions that the viewers are likely to have and puts the presenter on the spot. As others have said, the video is not entirely about SOLID but it's a valuable watch anyway and there's a lot of wisdom contained within.
Most of us are janitors!!! SO TRUE!!
love the back and forth between you two, great asides
That man deserves a cookie! Someone, get him a cookie ASAP, You, good sir, are a clear and effective communicator, wish we had you for training at work!
Hamza, I am available for training. We should discuss. Thank you for the kind words!
Thank you for the discussion at around 10 minutes on abstraction. That was great!
This entire Series on Design Patterns is extremely helpful ... i've seen it many times now... and at every iteration i always gain some new insight or a new idea. Robert and Phil make a Great Duo at exploring these concepts.... 14:00 ... it was a good segment... haha
This is the video I have been waiting for. Every developer must see this. Thanks a lot Microsoft
One of the best explanations I've heard.
I actually really appreciated him pushing back on DI
Great video. It give me a basic understanding of the different design patterns. I would also be interested in watching the follow up video that refactors code into a design pattern.
thanks for explaining by Phil and Robert for a\ such a important topic in software programing
Love the explanations and detail in this video!
14:00 was good, wish they didnt stop. Seems too often I have the same argument in the office.
Viewers are having fun. These are the conversations that are so interesting and rare as everyone is either so busy or afraid to discuss because they may not know as much and might look less competent. Debate everything on these videos! Please :)
We're just "janitors". Brutal and honest truth.
The link to the code samples in the description is dead... they can be found on GitHub here:
github.com/skimedic/presentations
This is jumping ALL over the place!!!!!
Excelent questions by Robert.
I understand the idea and the reason for using design patterns, there are some stuff I got lost, but I will review the book you recomnend. I find it hehe video useful because of the examples like what happens if I the card provider have different methods or if I have to change price in production without releasing a new version, that is where I find that implementing design patterns is a game changer, I have heard about them but I never feel like I was going to need them, I also thought it is over killing the project, but the example of the decorator pattern brings maintainability, instead of creating new classes for each possibility, I wouldn't realize that before if I wasn't watched this video. Thanks for the insight about design patterns, hope you have done the examples with the old school way and the design pattern way.
Also a Contrasting Comparison of Code with and without these patterns as suggested by Robert at 55:00 would be a Great Idea... may be a git repository with both kind of codes .... would answer so many questions and deliver the reason behind these patterns as well.
Very good video about how to become good developer.
the Clean Code is best one of my favorite books.
especialy boy scout principle is very helpful to me to make software better than before.
Should do one *only* on SOLID principles. This was good but a bit too much interruption at places for my liking. Keep up the good work.
One thing I dont get is why to use factories in the first place. Correct me if Im wrong but the shown example of the so called "Simple Factory" violates the OCP principle because everytime I add a new Type of pizza I have to create a new class for it and then modify the factory class to be able to create an instance of the new class through the factory and I also need to create a new entry in the PizzaType Enum. Can somebody explain this to me
Good talks Sirs. It is very helpful. Thanks a lot! I'm looking forward to see the follow up show, the refractoring. :)
Just in case anyone is wondering the plural of moose is just moose.
Very good and very easy to listen to.
Was there ever a follow up episode where they had examples of the "not optimal" way of coding?
Moose plural is Moose, ajajjaj. I google it.
I learned a lot with you guys. You're awesome.
Just a warning to future viewers because this wasn't clear to me: Only about 10 minutes of the video is actually about the SOLID principles directly. The majority of the video focuses on OOP design patterns and how they can be used to implement the SOLID principles. It actually says this in the video description but the title of the of video was misleading.
I think header should be something like SOLID & Common Design Pattern. I was here and thought I would have SOLID all they way.
I had no idea Steve Carell had a Visual Studio show.
lol i see it now.
lol
“The three hardest things in software development are naming conventions and off-by-one errors” - I bet that is not his but pretty good.
Uncle Bob does this better. He keeps my attention and he's so clear why we need to adhere to SOLID. I'm currently refactoring a monolithic 8000 lines of code written by a mathematician. It's been hacked to death by two others so far "code rot". Down to 4600 lines in 3 days. Don't let maths guys write code
7:42 - Maibock, yeah that's the beer I was thinking of.
Only thing about the decorator: if you don't know (or in this case, the ICar doesn't know/care) what you have already done, how to you enforce certain boundaries? I don't want to "armor the car" a couple of times and suddenly have negative speed...
I really liked the talk, but where are the next parts? Robert mentioned a future refactoring talk.
I would definitely read Head First Design Patterns, like Philip said, to understand the language of the seniors devs.
Around 24:00 ... single responsibility principle? Whenever you want to add new type of pizza, you have to modify class factory. What if you want to have BetterPizzas.dll containing several new types? Isn't it better to include class factory into possibly several files and register all available PizzaFactories and their IDs from outside during program initialization?
I couldn't find the source code on link , can you please share it on somewhere else ? source code looks rather instructive.
love this thank you
I actually really enjoyed the off-by-one joke ;)
Just wonder why he put properties on the interface which he could put it in an abstract base class.
I Love what you guys are doing..., giving those of us that are fairly new to programming a way of understanding how to program beyond an understanding of an introduction to C#. However, it would be nice if you think of the Newbie, when you say "The Goal is not to bend developers to the will of some Specific Pattern, but to get them to think about what they are doing" the Phil Haack quote, that should not be directed at Newbies because some one new to Programming may understand the basics of the C# or whatever language, but may not have any Idea of how to Structure their code to good effect. Having a good understanding of the various patterns out there..., especially the Gang of Four Patters provides a baseline for Developing code. Only after understanding the Basic Design Patterns can a Programmer be in a Position to "Think about what they are doing" in a way that adds value... Anyway as a Newbie, I just wanted to share this view with you guys. Please keep helping us New Programmer become good at our craft and focus on us at least as much as you do the choir..., those that already know the concepts you are sharing... Tim (Retired Navy; New Programmer...)
I really liked the show, but I'm dissapointed that I can't find related videos in one place, I have to check it on RUclips.
14:31 is why you need to understand SOLID principles
In 27:27 Philip explains why he uses easy examples instead of complex ones
2:38 this is gold!
not once everytime i feel oh man how can they wrote in this manner but finally checking commit history :P the name looks very familiar :)
Would think that IPizza wouldn’t have cut, bake, or box within it...following the single responsibility + general OOP principles
I agree, it also has properties on it which I think should be in an abstract pizza class.
This could have been SO much better if they spent a little more time in the editing room adding watermarks, flyovers, or anything to show transitions between the principles and which patterns implemented which principles.
link to the Code doesnt work. can you update it? ty
I do not think the Service vs Inversion was answered. They seem the same. They all use, somewhere, the "real" implementation which is based on the Interface contract or an Abstract class.
I've seen old C++ projects with huge relational diagrams based on classes that have been inherited and inherited and inherited. Not pretty, this pattern seems to be heading in the same direction!
whether this code is available in github? If so link please.
So, what was dubbed "SOLID design patterns" turned into "design patterns". Hmm...
The example with chganging the bit on tap in a bar made me smile, that cab somtimes depend on hu suplies the beeer, if yhe suplyier owns the taps and the thanks (yes this sometimes happens) you can’t changes to beer firm another suokier/ producer as you will incur custs when your current suplier comes and tekaes ther taps, raks ans compressor back. sorry if this was ot grat video
what is the best design pattern?
Who came here after getting frustrated with uncle Bob not getting past O of SOLID.
same here. he was talking water too much
So... thinking of it like functional programming, but not?
What is the purpose of _naming?
Edit:
I am referring to: _instance (at 20:45 for instance)
Seems like it's used for members to differentiate them from parameters and local variables. We are using m_name, I've seen name_ in some code.
I think we can better explain these concepts with real life simple examples instead of funny/cartoony ones.
Phil explains that choice in the video.
OMG, you explained what was there well enough, but... lock (_syncLock) return x ?? (x = new MySingletonClass()); / not the point of the exercise, I don't think, but you see the difference...
Good that the show owner asked specific questions about SOLID, is not easy to understand, why people pass so fast to it when they are explained? I wished they had not stopped discussing about real examples.
Liskov is only notional on the CLI
Pleased I found this video.
6:52 - Why did they even bring this guy in if he's not a beer expert?
j/k i love this guy lol. I also suspect he knows more about beer than he's letting on.
I'm about 2 programming languages late lol Thanks +1!
The mapping stuff at 33 minutes seems really harmful. Would be very confusing to encounter.
53:41 the cheese is making him hungry
code samples gone!!!
Janitor here 😃
I watch many video's on this channel, but this one piqued my interest only to let me down. Too much about design patterns and not enough SOLID information. Also, it felt like Robert was lost most of the time like many people I'm sure that were trying to follow along. But the details were glossed over, and the reasons for doing the patterns were difficult to understand. I think this was mostly because he was trying to cram too much information in too short a time. This would have been better had it been broken up into multiple videos with more time dedicated to each pattern and how that patterns helps make SOLID code.
In real-world application development, everything is a tradeoff and he is using his experience to touch those boundaries. If all you want to do is learn SOLID designs without becoming aware of its tendency to become bloat wear look elsewhere...
You may want to go over to Christopher Okhravi's YT channel and pick up on the SOLID and Design Patterns playlists.
This video in itself violated the Single Responsibility Principle which is very ironic. Trying to do too much in a single video. Like he said with regards to the number of files in a project "so what?!" if you end up with many videos. Break this down into single topics.
Simple Factory - makes no sense. I guess that is why the Gang of Four did not mention it. What do you gain from a factory method? "I want to have one place where I create. I don't want to create from multiple places " - why??? You might as well call the constructor directly wherever you need to create the object.. The proper answer is that you want to avoid dependency. You are looking to solve this with an inversion of control. In this case, you are employing a separate factory. Hence, if the CEO asks you to change the "new CreditCardA()" to "new CreditCardB()" - you don't need to touch the [sensitive] Client. Rather, you just modify the factory class/function.
Because if you add new type you would have to modify every switch/if statement where you use to create objects its just so you minimize if statetements for creating objects to one and only place. Simple factory is made for one family of object where you would use factory method for multiple families of object like the example for diffrent pizza stores. You are right on the money with dependencies.
"Because if you add new type you would have to modify every switch/if statement where you use to create objects its just so you minimize if statetements for creating objects to one and only place" - that's called "don't repeat yourself". It is not a "creational" design pattern.
Assaf Wodeslavsky It still is some sort of a pattern because it is widely used.
Yes - it is called - "a function".
I agree that he's full of nonsense. But the question that he is raising - about the change of credit card 💳 - is a good one. Resolving the dependency on a concretion by inversion of control - like dependency injection - is a good solution. But his jumping to the example of the"moose and flying squirrel" - is the problem. It's a terrible example when u have the credit card example staring at your face.
Thank you, Microsoft.
"pretend the next person looking at your code is an axe wielding psychopath ... in reality who is looking at your code next is probably you" I would not see that as a contradiction :-D
Why would you write a method that does 2 things?
Exactly, I don't understand why anyone would ev3n stop at 2 things. I personally like to put the entire program into public static main. All the code conveniently located in one location.
Ok, mh. Thanks.
The anti-pattern, antithesis of DRY, or W.E.T., We Enjoy Typing. Been there, seen that, try to avoid it at all costs.
Came across another one recently, DAMP. Descriptive and Meanful Phrases. Made me laugh.
Can anyone write a C program without using semi colon anywhere... Just a Hello world program... no semi colon
Interface what? I come from this background and I'm not sure that wasn't a clumsy anecdotal illustration.
I know this is a year late... If you're still curious, Tim Corey has a great video on interfaces. He also has one on the Liskov Substitution Principle.
The guy in the white shirt always asks the same questions I have.
LMAO, this guy is hilarious. The three hardest things in Software development.
Great talk, but this video lacks one thing. He talks about things but doesn't show the code (0:00-20:00). He speaks the code outloud and you can imagine it, but looking at it and make changes to it to show what's going on would change my rating of it from 7/10 to 10/10. Little, though very important detail.
I really like the video anyway. A bit too chaotic but a good one.
This guy looks like Michael Scott's brother
I stopped after the SOLID discussion because I didn't find it very useful or good.
He blew through the names in the list very quickly, and did not use their full names when he did, and didn't explain that their first letters is where SOLID comes from. He could have simply laid out a nice, full visual similar to this (but better formatted than I do here).
S = SRP = Single Responsibility Principle
O = OCP = Open Closed Principle
L = LSP = Liskov Substitution Principle
I = ISP = Interface Segregation Principle
D = DIP = Dependency Inversion Principle
His description of LSP was not right: it's not "program to interfaces".
He didn't explain the main problems that ISP is meant to solve - it's not just that interfaces are too big, there are problems with IMPLEMENTING large interfaces. So you don't really know WHY you should use ISP.
His discussion of DIP was all over the place.
I think someone unfamiliar with SOLID would miss out on a lot of simple things, whereas someone already familiar with SOLID would not learn anything new.
I'm a little unclear how 'programming to an interface', described in the Liskov Substition Principle discussion, differs from Dependency Injection in Phil's explanation.
15:06
A poor man's Uncle Bob
GPL best
اذا امكن ترجمة المقاطع للغة العربية .
get{ if (_instance == null){ lock (_syncLock){ _instance = new MySingletonClass(); } } return _instance; }
That first test he shows is sort of funny? If Assert.AreSame does not fail then the remaining asserts are pointless.
talk about design principles next time
Steve Carell on the right
And Fisk from Daredevil on the left!!
what weird analogies :/ the dude is mixing dependency injection with dependency inversion...
Wish the other guy would stop saying "Ok", "Aha..."
Adapter - the example with the Moose and FlyingSquirl has nothing to do with Adapter.
Instead - the purpose of the adapter is to allow two (a ClientA and a ServerB) PRE-WRITTEN / tested / proven / signed classes to interact WITHOUT making code modifications. Even though they can't - because the ClientA is unaware of the ServerB. Instead, ClientA is designed for ServerA. Solution: Adapter Pattern. We build a new ServerA2 that looks identical (in the eyes of ClientA) as ServerA. ServerA2 is aware of ServerB and actually exposes its functionality to ClientA.
There are different types of adapters. What was presented here was just one of the few that are common. You should do your reading before acting all high and mighty just because you learned about one thing, and didn't even learn it properly.
i'd be happy to retract, if you show me your sources. in wikipedia, i only found one adapter pattern. en.wikipedia.org/wiki/Adapter_pattern
+Assaf Wodeslavsky
How about you actually try reading your link to wikipedia.
You're not going to retract because you have too much pride, which is already made evident with you trying to act smart and giving me a link that you haven't even read for yourself.
Here are some texts for you to read for descriptions and examples of Adapters being put to use:
Design Patterns: Elements of Reusable Object-Oriented Software
Agile Principles, Patterns, and Practices in C#
Clean Code: A handbook of Agile Software Craftsmanship
98luk45 1. please stop attacking my person. 2. Please include a link and a quote from said link, supporting your position.
I've included 3 books in my previous comment if you know how to click on the 'Read more'. I don't need to show links, stop being lazy and read. I'm not here to spoon feed you - heck, you're not even going to open your mouth even if I was going to spoon feed you.
You guys have to keep this vids for under 30 mins. No one has an hour.
Idealistic BS, these guys never seen real code I guess...SOLID, Design Patterns all is taken backwards today and use whether is beneficial or not. Back in the days we created such solutions called today design patterns and we used them only there where was needed. Today programmers start with design pattern instead of even thinking....
This co host constantly interrupts this dude at every important point. To the point that he simply not make a any consistent or meaningful explanations I would of told him to follow the pattern that he needed to apply the STFU pattern.
This is why I like to have nothing to do with object orientated programming...
SOLID is a set of Design Principles, not Design Patterns! Do not create confusion. You do not have to make BS videos if you can't get the basics right!